home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19990725-20000114 / 000050_news@columbia.edu _Mon Aug 23 12:18:48 1999.msg < prev    next >
Internet Message Format  |  2020-01-01  |  5KB
  1. Return-Path: <news@columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.59.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id MAA04065
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Mon, 23 Aug 1999 12:18:48 -0400 (EDT)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id MAA11169
  7.     for kermit.misc@watsun.cc.columbia.edu; Mon, 23 Aug 1999 12:04:16 -0400 (EDT)
  8. X-Authentication-Warning: newsmaster.cc.columbia.edu: news set sender to <news> using -f
  9. From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
  10. Subject: Re: Downloading gz files using C-Kermit, Linux, & Lynx
  11. Date: 23 Aug 1999 16:04:15 GMT
  12. Organization: Columbia University
  13. Message-ID: <7prrdv$asu$1@newsmaster.cc.columbia.edu>
  14. To: kermit.misc@columbia.edu
  15.  
  16. In article <37C166B2.3F55@radium.ncsc.mil>,
  17. James S. Johnson <jjohnson@radium.ncsc.mil> wrote:
  18. : I have a perplexing problem using C-Kermit to download files.
  19. : 
  20. : The local public library offers a Lynx connection to the internet. I
  21. : have three communications programs that I use to connect -
  22. : Hyperterm/Win95, C-Kermit/Linux(Slackware4.0), and MS-Kermit/Win95's
  23. : DOS. Both C-Kermit and MS-Kermit come from www.columbia.edu. I log in as
  24. : guest, and I cannot change settings on the library's Lynx setup. I am
  25. : able to examine downloaded files with a binary editor.
  26. : 
  27. : I can download *.exe files without a problem. However, I cannot
  28. : correctly download *.gz files. Under Hyperterm and MS-Kermit, the files
  29. : have a 0x0D (hexadecimal for 13) byte inserted before every 0x0A byte.
  30. : Under C-Kermit, the files have all the 0x0D's stripped.
  31. :
  32. This indicates that C-Kermit is in text mode.
  33.  
  34. : Except for the
  35. : fact that I can download *.exe files, this appears to be a problem with
  36. : the text/binary setting. I have tried everything I can think of to make
  37. : certain the setting is on binary, but without solving the problem.
  38. : 
  39. It won't do any good to put C-Kermit in binary mode if Lynx is sending
  40. the file in text mode -- by the time C-Kermit gets it, it is already
  41. corrupt.
  42.  
  43. : One odd thing I have noticed - using C-Kermit I can turn the automatic
  44. : receive switch off, so I have to explicitly go to Kermit and start the
  45. : receive part of the transfer. When I do so, I see a banner that tells me
  46. : the transfer is in binary mode, but after about 10 packets are received
  47. : it switches to text mode. This is bewildering.
  48. :
  49. This means that the Kermit program on the Lynx end has sent the file in
  50. text mode and has announced that it is text in the file attribute packet,
  51. which comes after several other preliminary packets.
  52.  
  53. : It tells me that I am
  54. : indeed correctly putting Kermit into binary mode, but that (1) Lynx is
  55. : switching me back to text mode without my knowledge...
  56. :
  57. Yes.
  58.  
  59. : (2) my C-Kermit has
  60. : an automatic switch set to change me back to text mode if it sees a
  61. : particular byte sequence in the incoming data, which is coincidentally
  62. : in the *.gz files I have attempted to download...
  63. :
  64. No, C-Kermit doesn't do anything like that.  When receiving files, it
  65. follows the file type announced by the sender.  The sender always governs
  66. the transfer mode.
  67.  
  68. , or (3) the banner
  69. : doesn't actually reflect the setting of C-Kermit, but instead is just
  70. : notifying me that the file appears to be a text file.
  71. :
  72. No, the banner tells you the actual transfer mode.
  73.  
  74. : Just to make sure
  75. : (2) isn't the culprit, I've turned off all the automatic functionality I
  76. : can find, with no change in the final results - the received files under
  77. : C-Kermit still have the 0x0D's stripped. Also, HyperTerm appears to be
  78. : in text mode, too, even though I use the receive command, which the
  79. : HyperTerm documentation says is a binary transfer. So I don't believe
  80. : that C-Kermit is switching automatically, and I do believe that it is
  81. : set to binary mode when the transfer begins.
  82. : 
  83. I don't think HyperTerm actually makes any distinction between text and
  84. binary mode.  Old versions of MS-DOS Kermit didn't either (pre-3.0).
  85.  
  86. : Frank DaCruz' _Using C-Kermit_ has a single (as far as I can find)
  87. : reference to Lynx. It is on pg. 536, I think, around the middle of the
  88. : page, and it refers to a problem running C-Kermit under VMS when
  89. : communicating with Lynx. Unfortunately I don't know what OS the
  90. : library's Lynx runs under. Does Lynx and C-Kermit have a known problem
  91. : when it comes to downloading *.gz files, or is there something else that
  92. : I should try to get the downloads to work?
  93. : 
  94. I don't know a lot about Lynx, but I understand that its file-transfer 
  95. options are configured at startup.  Its startup file contains lines like:
  96.  
  97.   DOWNLOADER:Kermit binary download:/opt/bin/kermit -i -V -s %s -a %s:TRUE
  98.   DOWNLOADER:Kermit text download:/opt/bin/kermit -s %s -a %s:TRUE
  99.   UPLOADER:Kermit binary upload:/opt/bin/kermit -i -r -a %s:TRUE
  100.   UPLOADER:Kermit text upload:/opt/bin/kermit -r -a %s:TRUE
  101.   UPLOADER:Kermit text get:/opt/bin/kermit -g %s:TRUE
  102.   UPLOADER:Kermit binary get:/opt/bin/kermit -ig %s:TRUE
  103.  
  104. But this doesn't reveal anything about how it tells the difference between a
  105. text file and a binary file.  I suspect that somewhere else in its
  106. configuration, there is a list of binary filetypes (like ".exe") and text
  107. filetypes (like ".txt").  Either (a) ".gz" is erroneously listed as text,
  108. or (more likely) (b) ".gz" is not listed and the default for unlisted types
  109. is text.
  110.  
  111. - Frank